-
Notifications
You must be signed in to change notification settings - Fork 121
Domain settings: feature flag, entry point from settings, barebone UI #8581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* trunk: (38 commits) Hide card present payments related actions for countries where IPP is not supported. Fix filename in comment. EntityIDMapper - Add unit tests. Rename error for clarity. EntityIDMapper - Handle JSON with/without data envelope. ProductIDMapper - Add unit tests. ProductIDMapper - Handle JSON with/without data envelope. Product IDs - Add mock json without data envelope. Rename type alias. `ProductSkuMapperTests` - Test mock json file without data envelope. `ProductSkuMapper` - Handle JSON with/without data envelope. Add product sku mock JSON without data envelope. Update unit tests to use a for loop to handle array of array. Parse both JSON and return an array of array. Introduce parsing error. Make ProductListMapper parse JSON with/without data envelope. Add mock product list JSON without data envelope. Update unit tests to test an array of products. Make `mapLoadProductResponse` return an array of parsed products from with/without data mock JSON files. Add an error for parsing failure. ... # Conflicts: # WooCommerce/WooCommerce.xcodeproj/project.pbxproj
You can test the changes from this Pull Request by:
|
itsmeichigo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works as expected ✅
| // TODO: 8558 - show domain list with search domain action | ||
| } | ||
| } | ||
| .padding(.init(top: 39, leading: 16, bottom: 16, trailing: 16)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we make these numbers constants?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like it's more useful making layout constants for shared styles within the view or reusable components, while these one-off constants are just from the design for this particular screen. Do you feel like having these layout constants helps with readability and future maintenance? If so I can make constants for these, would just like to hear more thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm under the impression that our convention has been to keep layout measurements at one place for quickly adjustments when needed. I don't have a strong opinion on this, just want to make sure that we are consistent with other parts of the app 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I didn't do enough SwiftUI to know that we have this convention. I'll ask the team later but just moved them to constants in any case d3f71c6.
|
|
||
| var body: some View { | ||
| ScrollView { | ||
| VStack(alignment: .leading, spacing: 36) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we make this number constant as well?
| } | ||
| } | ||
| .navigationBarTitle(Localization.title) | ||
| .navigationBarTitleDisplayMode(.large) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Do we need to do something to make this title appears large? Currently, it looks like the default style.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, this screen isn't meant to have a large title based on the latest design VyLr7LvKodHE4kINfBE7Lw-fi-682%3A40227&t=gKEdaIp9JraK2sED-0. Updated in c2c3e9b.
To answer the question about why the large title isn't working: it's because the SwiftUI view is embedded in a UIHostingController, and large titles need to be enabled for its navigation controller's navigation bar like navigationBar.prefersLargeTitles = true.
| if viewModel.domains.isEmpty { | ||
| VStack { | ||
| Divider() | ||
| .frame(height: Layout.dividerHeight) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓Non-blocking: do we really need to set a height or the divider? I usually keep the frame as-is, as I think the default style works well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default height isn't mentioned in the official documentation 🤔 I feel like it's safer setting a height just in case the default behavior changes in future iOS versions so that there are no surprises.
| let domain: DomainSettingsViewModel.FreeStagingDomain | ||
|
|
||
| var body: some View { | ||
| VStack(alignment: .leading, spacing: 8) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we make this number a constant too?
Part of #8558
Description
Why
After the user creates a store, they might want to choose a proper domain for their new store. This is part of the onboarding plan for the future, until then we're showing the entry point in Menu tab > Settings > Store settings.
Implementation
This is the first PR of the domain settings, with a feature flag, an entry point in the settings, and a basic UI with mock data. The entry point is only shown when the feature is enabled and the site is a WPCOM site. Some barebone data models in the Networking layer were created to streamline the UI integration, and the Yosemite actions just return mock data for now.
Data layer
Two endpoints are required to show the UI on this screen:
DomainAction.loadDomains: this loads the site's domains, including the free staging domainPaymentAction.loadSiteCurrentPlan: this loads the site's WPCOM plans, and returns the current plan to determine if the site has domain credit so that the user can pick a domain for free (available from certain WPCOM plans)UI
The main SwiftUI view is
DomainSettingsView, which shows the free*.wpcomstaging.comdomain at the top withFreeStagingDomainView. Below the free domain, different content can be shown with the following logic:Search for a domainis shown (the CTA is implemented in this PR without the details text below)Testing instructions
Prerequisite: a WC store with a WPCOM plan is required
Domainrow under the store settings sectionDomainrow --> a modal should be shown with a free staging domain at the top (mock data) and a CTA at the bottomScreenshots
RELEASE-NOTES.txtif necessary.